% This file is part of the i10 thesis template developed and used by the
% Media Computing Group at RWTH Aachen University.
% The current version of this template can be obtained at
% <http://www.media.informatik.rwth-aachen.de/karrer.html>.

\chapter{Concepts}
\label{Concepts} 



\begin{figure}
	\centering
	\includegraphics[width=\fullwidth]{images/aSampleSupplyChain(rotated).pdf}
	\caption{The supply chain}
	\label{fig:thesupplychain}
\end{figure}


\chapterquote {A supply chain is a web of autonomous enterprises collectively responsible for satisfying the customer by creating an extended enterprise that conducts all phases of design, procurement, manufacturing, and distribution of products} {~\fullcite{Whitman:1999}}

Figure \ref{fig:thesupplychain} describes a simple supply chain. It consists of one manufacturer, many distributors, wholesalers, retailers and Customers. Black arrows indicate item flows from manufacturer to customers. To ease the management of items flow in and out, every company employs an EPCIS Server. Then, all the item flows are converted into EPC events stored in the EPCIS Server's repositories. With these systems, product information are efficiently managed and shared between participants in Supply Chain (SC). Many applications are available with the help of Supply Chain Management System (SCMS). Applications like anti-counterfeit and item callback are available by cooperation of participants in a traceability network. However, item information usually is highly confidential property of companies. ''Who can know about my up level manufacturer or down stream buyer?''  ''Who is allowed or not allowed to access which part of my item information with what kind of permission? ''The answers to this kind of questions are usually come form privilege computations based on roles. There is though an urgent need to employ an access control mechanism in the SC participant's information sharing.

An Extended Role-based Access Control (ERBAC) system is proposed to deal with access control in a traceability network. It enables every participant in the traceability network to control access requests from other participants in the same traceability network, and give proper privileges to others based on General and Perspective roles in the traceability network. Every participant in the traceability network employs an ERBAC server to deal with access control requests. And there is a RSS server deal with role administration for the traceability network.

In the ERBAC system, computation of privileges for a role assigned to a participant is same as in traditional RBAC. But it differentiates from traditional RBAC system in its innovative ways to address the problems in role types define, role's association with EPCClass or EPCClass range and role administration under a distributed environment.

\section{ERBAC infrastructures}

This section introduces infrastructure of ERBAC and explains how each part works in a traceability network. 

%\myBigFigure	
%	{infrastructure}
%	{Infrastructure of ERBAC}
%	{Infrastructure of ERBAC}

ERBAC mainly consists of two primary elements: Role Service Servers (RSS) and ERBAC servers. RSS is a web server run by trusted third party. RSS maintains a General Role Dictionary and keeps it update in every ERBAC servers (Details about General Role are described in \ref{sec:roletypes}). The other main task for RSS is dealing with Role Administration like: Role Assignment \ref{sec:rolegrant}, Role Revocation \ref{sec:rolerevoke}, Role Extension \ref{sec:addrole} and Role Delete \ref{sec:deleterole}. RSS has information about all participants' addresses for the sake of verification and update, but it does not provide any service to access this information for the security reasons. All services provided by RSS should be implemented as Web Service, so they can be found by a lookup service, and they are scalable in an open and distributed environment. ERBAC servers are usually employed by participants of the traceability network. They not only deal with queries, but also maintain role hierarchies and compute privileges for requestors based on provided roles.

%The IBM Theseos team provides a RFID data generator\footnote{It can be downloaded here: \href{http://www.almaden.ibm.com/cs/projects/iis/rfid/}{http://www.almaden.ibm.com/cs/projects/iis/rfid/}} for traceability implementation. It can generate necessary fundamental data schema for ERBAC system. For ERBAC concept, we choose part of their data schemas to make our concept compatible with current traceability implementation. A company plans to employ an ERBAC system can modify these schemas to fits its own requirements.
%
%\subsubsection{Data schemas in ERBAC servers}
%
%In the following, relational schemas for in participant's ERBAC server are presented. Data records are stored in the database of ERBAC server of each participant in the traceability network. The tuples are stored in the form of comma separated values for easy uploading into a database.
%
%Four relations are universal in the sense that they are part of the data model and therefore present in all three architectures (data warehouse, EPCglobal, process-and-forward). Because in the traceability network, most applications focus on flow track of items, process-and-forward architecture's database design has been chosen. Therefore, the generator's result will be stored in separate files for each server. 
%
%The table \emph{event} contains all sensing events and the event location, some address information, i.e. some description, of the locations under the control of a participant. The table \emph{sProp} stores static data about entities, i.e. attributes that do not change over the lifetime of the entity. The attributes for which data is generated are the entity's color (a string randomly chosen from a set of configurable values; see \ref{fig:generator.cfg}), and the minimal and maximal allowed storage temperature for this entity (integer value randomly chosen from a range of -100 to +100).
%
%The table \emph{contains} stores which entities are associated with each other, which means which objects are put into other objects at a particular location and point in time. For all location and time-points thereafter, only events for the outer, containing entity are generated, but not for the contained entities anymore.
%
%In the following are data schemas defined:
%
%\emph{\textbf{event}(eid char(12) not null, lid varchar(50) not null, ts timestamp not null, primary key (eid, lid, ts))}
%
%\emph{\textbf{location}(lid varchar(50) not null primary key, address varchar(100))}
%
%\emph{\textbf{sProp}(eid char(12) not null primary key, color varchar(20), minTemperature Integer, maxTemperature Integer)}
%
%\emph{\textbf{contains}(eid char(12) not null, contained eid char(12) not null, ts timestamp not null, primary key (eid, contained eid, ts))}
%
%If data for the EPCglobal approach is required, two tables for the central services Object Naming Service (ONS) and Discovery Service (DS) are created. However, based on distributed environment set up in this thesis, there is no central management service except Role Service. Therefore, data schemas of ONS and DS will not be used. However, to give the reader a complete view of the data base design, these two data schemas are presented here:
%
%\emph{\textbf{ONS}(eid char(12) not null, dbid varchar(50) not null, ts timestamp not null, primary key(eid, dbid))}
%
%\emph{\textbf{DS}(eid char(12) not null, dbid varchar(50) not null, ts timestamp not null, primary key(eid, dbid, ts))}
%
%For the process-and-forward approach, information about the item track is not stored in a central service but instead is distributed over the \emph{receivedFrom} and \emph{sentTo} tables present at each participant. The data is stored in the following schemas:
%
%\emph{\textbf{receivedFrom}(eid char(12) not null, dbid varchar(50), ts timestamp not null, primary key(eid, ts))}
%
%\emph{\textbf{sentTo}(eid char(12) not null, dbid varchar(50), ts timestamp not null, primary key(eid, ts))}
\subsection{Database Design}
\label{sec:databasedesign}

Databases in RSS and ERBAC servers mainly store information about item track and role grant.

\subsubsection{Data schemas in ERBAC servers}

In the following, relational schemas for in participant's ERBAC server are presented. Data records are stored in the database of ERBAC server of each participant in the traceability network. Figure \ref{image_umlerbac} is a diagram of the data schemas in the ERBAC server.  \\

\myFigure
{umlerbac}
{Data schemas in ERBAC servers(1)}
{Data schemas in ERBAC servers(1)}

The table \emph{event} contains all sensing events and the event location, some address information, i.e. some description, of the locations under the control of a participant. The table \emph{sProp} stores static data about entities, i.e. attributes that do not change over the lifetime of the entity. The entity's color and the minimal and maximal allowed storage temperature for this entity (integer value randomly chosen from a range of -100 to +100).%The attributes for which data is generated are the entity's color (a string randomly chosen from a set of configurable values; see \ref{fig:generator.cfg}), and the minimal and maximal allowed storage temperature for this entity (integer value randomly chosen from a range of -100 to +100).

The table \emph{contains} stores which entities are associated with each other, which means which objects are put into other objects at a particular location and point in time. For all location and time-points thereafter, only events for the outer, containing entity are generated, but not for the contained entities anymore.

In the following are data schemas defined:

\emph{\textbf{event}(eid char(12) not null, lid varchar(50) not null, ts timestamp not null, primary key (eid, lid, ts))}

\emph{\textbf{location}(lid varchar(50) not null primary key, address varchar(100))}

\emph{\textbf{sProp}(eid char(12) not null primary key, color varchar(20), minTemperature Integer, maxTemperature Integer)}

\emph{\textbf{contains}(eid char(12) not null, contained eid char(12) not null, ts timestamp not null, primary key (eid, contained eid, ts))}


\emph{\textbf{receivedFrom}(eid char(12) not null, dbid varchar(50), ts timestamp not null, primary key(eid, ts))}

\emph{\textbf{sentTo}(eid char(12) not null, dbid varchar(50), ts timestamp not null, primary key(eid, ts))}

These data schemas are defined to compatible for a RFID data generator\footnote{It can be downloaded here: \href{http://www.almaden.ibm.com/cs/projects/iis/rfid/}{http://www.almaden.ibm.com/cs/projects/iis/rfid/}}, which is the data generator of  Theseos, a current traceability network implementation. A company plans to employ an ERBAC system can modify these schemas to fit its own requirements. 

\myFigure
{umlerbac1}
{Data schemas in ERBAC servers(2)}
{Data schemas in ERBAC servers(2)}

For the needs to authorize requests in ERBAC server, we deal with authorization and privilege inheritance with two schemas in our concept: \emph{roleGrant} and \emph{roleHierarchy}. Figure \ref{image_umlerbac1} is the diagram of these two schemas.

Table \emph{roleGrant} stores General Role and Perspective Role grant information for companies. If a company gets a role granted, a record about company's information, association EPC Class and expire date will be inserted into this table. By default, expire date will be set to one year after the date that the role is granted. In contrast, a record about company's information, association EPC Class and expire date will be deleted from this table when a company's role is revoked. Table \emph{roleHierarchy} stores information about role's relationship for privilege inheritance. General Roles and Perspective Roles are structured as arbitrary tree. The position of a role is a 5 bits integer by default which means in the current schema only 5 layers are support in the role hierarchy. However, it is easy to extend the depth of role hierarchy by extend the integer range. More details about the how role hierarchy works can be found in \ref{sec:rolehierarchy1} and \ref{sec:votealgorithm}.

\emph{\textbf{roleGrant}(lid int not null,	EPCClass char(18) not null,	roleName varchar(80),	expireDate date, primary key (lid,EPCClass))}

\emph{\textbf{roleHierarchy}(roleName varchar(80) not null primary key,	position int)}

\subsubsection{Data schemas in RSS}
\label{sec:dataschemasinrss}

\myFigure{ERrss}
{Data schemas in RSS}
{Data schemas in RSS}

Figure \ref{image_ERrss} describes four data schemas in the RSS's database.

\emph{\textbf{company}(lid int not null primary key, comName varchar(50), address varchar(100))}\\
Table \emph{company} stores all company's information in the traceability. For the security reason, RSS provides no interface to access this information, and authority to access this data should be provided very carefully.

\emph{\textbf{roleGrant}(lid int not null, 	EPCClass char(18) not null,	roleName varchar(80),	expireDate date, primary key (lid,EPCClass))}\\
Table \emph{roleGrant} stores General Role grant information about companies. If a company gets a General Role granted, a record about company's information, association EPC Class and expire date will be inserted into this table. By default, expire date will be set to one year after the date that the role is granted. In contrast, a record about company's information, association EPC Class and expire date will be deleted from this table when a company's General Role is revoked. 

\emph{\textbf{itemTrack}(EPC char(27) not null, lid\_from int not null, lid\_to  int not null, ts timestamp,	primary key (EPC, lid\_from))}\\
When an EPC event occurs in the traceability, the participant registers it to RSS server. With the help data conversion middleware, events can be converted into data records in this table. RSS uses this table's information to look for voting partners for the grantRole feature\ref{sec:rolegrant}. 

\emph{\textbf{roleDictionary}(roleName varchar(80) not null primary key,	ts timestamp)}\\
Table \emph{roleDictionary} stores all General Role's names. The role's name is the primary key of the table so that there is no duplicate General Role defined in RSS.

%\emph{\textbf{roleGrant}(lid varchar(50) not null, EPCClass varchar(50) not null, comName varchar(50) not null, roleID char(12), roleName varchar(20), expireDate date, primary key(address, EPCClass))}
%
%Companies' information is stored in company table:
%
%\emph{\textbf{company}(lid varchar(50) not null primary key, comName varchar(50) not null, address varchar(100))}
%
%All General Roles' name is stored in a hashset \emph{roleDictionary}.
%
%To enable a lookup service for voting partners, there is a schema \emph{itemTrack} stores item track information:
%
%\emph{\textbf{itemTrack}(EPC char(27) not null, lid\_from int not null, lid\_to  int not null, ts timestamp,	primary key (EPC, lid\_from))}
%
%RSS maintains General Role Dictionary, we use a schema \emph{roleDictionary} to store General Roles' information. The role's name is the primary key of the table so that there is no duplicate General Roles defined in RSS:
%
%\emph{\textbf{roleDictionary}(roleName varchar(80) not null primary key,	ts timestamp)}


\subsection{Role Hierarchy}
\label{sec:rolehierarchy}

\myBigFigure	
	{rolehierarchy}
	{Role Hierarchy in single EPCIS server}
	{Role Hierarchy in single EPCIS server}
	
ERBAC system defines role hierarchy like in Figure \ref{image_rolehierarchy} to deal with authorization and privilege inheritance. In Figure \ref{image_rolehierarchy}, Perspective Roles and General Roles are structured together. From bottom to top, roles become more specific. At the bottom of the figure, there is a Company role connecting all the General Roles logically. At the second layer from the bottom, there are General Roles like Manufacturer, Distributor, Wholesaler and Retailer. These General Roles are assigned certain different privileges that can be inherited by their up level roles. All roles upper than General Roles are Perspective Roles, They inherits General Roles' privileges and have more specific privileges. In Figure\ref{image_rolehierarchy}, Directed Connected Wholesaler and Competitive Wholesaler lies on the Wholesaler. Directed Connected Wholesaler is a Wholesaler who has direct connection with current participant, it has more privileges than Wholesaler based on a fact that direct connected partner share more information than other relationship in a traceability network. The other role lies on the Wholesaler is the Competitive Wholesaler, this kind of roles are usually assigned to those Wholesalers while the role hierarchy owner also is a Wholesaler. Based on this role assignment knowledge, the role hierarchy owner can easily hide sensitive information from its Competitive Wholesalers. And for the higher level than Directed Connected Wholesaler and Competitive Wholesaler, there are more specific roles for product differences. They also inherit their predecessor's privileges and have more specific privileges in addition. Not only for the Wholesaler's branch in the role hierarchy, other branch roots like Manufacturer, Distributor and Retailers can have the same structures. How to use and implement the role hierarchy is discussed in detail in \ref{sec:usecases} and \ref{sec:rolehierarchy1} separately.

\section{Role types}
\label{sec:roletypes}

We define that two companies are directly connected when they have direct item transportation between each other. In Figure \ref{fig:thesupplychain}, Distributor2 is directly connected with Wholesaler1 and Wholesaler1 is directly connected with Retailer2 because they have the direct item flows with each other. Companies have this relationship call each other directed connected partners. Directly connected partners know each other well. They share not only item's information, but also other information like physical address, URL of server and so on. It is easy for one of them to grant the other roles on its own perspective views. These kinds of roles are defined as Perspective Roles because they are granted on a single company's view and independent of whole traceability network. 

For two companies are not directly connected, they have little information about each other. In most cases, they do not even know each other's existence before there comes an access request. In this case, it is hard to grant Perspective Roles based on direct connector's knowledge. Therefore, General Role is employed to deal with this type of access control request, which stands for a company's role in the whole traceability network. Role privilege table maintained in every participant's ERBAC Server and they can be used to compute privileges when a request comes from a company with a specific General Role. Conditions need to be satisfied when granting roles and how to grant roles will be explained in detail in the Role Grant section\ref{sec:rolegrant}.


\section{Role Constraints}


In traditional role-based control systems, roles are usually defined by the administrator or company's committee based on the result of a requirement analysis, and then roles are granted to subjects as needed. The system can predict all the roles that could appear, and each system is independent from each other. The administrator adds, deletes, grants and revokes roles without consideration about other systems. However, the story in a traceability network is different.

In a traceability network, a single company can play various roles. For example, a company A could play as Manufacture for Company C because it sells laptops assembled by itself to Company C. Meanwhile, it also plays a Retailer for Company D because it sells some CPUs to Company D. To deal with this issue, an innovative way to define roles for a company is proposed in this thesis.

As essential relationship between companies are set up by item transfer in a traceability network. Every company can play only one role for other company when associated with specific \emph{Object Class(es)}. In other words, two roles are mutually exclusive when associating with the same \emph{Object Class(es)}. (The Object Class is used by an EPC managing entity to identify a class or ''type'' of thing. These object class numbers, of course, must be unique within each General Manager Number domain. Examples of Object Classes could include case Stock Keeping Units of consumer-packaged goods or different structures in a highway system, like road signs, lighting poles, and bridges, where the managing entity is a County.) Based on this fact, it is a good idea to assign a role to company associating with Object Class(es). In the case described in the previous paragraph, we can describe the roles for Company A like this: Company A has the role Manufacturer with the item laptop (EPC: 01.0000A11.0001AF.*) to Company C and has the role Retailer with the CPU (EPC: 01.0200A11.0101CF.*) to Company D. 

With this policy of role assignment, all the roles that one company can be assigned are well managed with some EPCClass or EPCClass ranges. And with this role definition method, it is feasible to implement Role Administration services in a distributed environment.


\section{Role Administration}
\label{sec:roleadministration}

\subsection{Grant roles}
\label{sec:rolegrant}

\begin{figure}
	\centering
	\includegraphics[width=\fullwidth]{images/RoleGrant.pdf}
	\caption{Role Grant Environment}
	\label{fig:rolegrant}
\end{figure}


Figure \ref{fig:rolegrant} describes a simple ERBAC system. At the top of the figure, there is the most important part in the ERBAC system, the Role Service Server (RSS).  It is the RSS, who deals with role grant, revoke, add and delete issues. Below the RSS, there are several participants in the traceability network. Usually these participants are companies in one supply chain. In this figure, dotted arrows indicate that CompanyA have sent items to CompanyB, CompanyC and CompanyD and directed arrows are connections between companies and RSS.

%\todo{explain why role assignment, revoke, administration(extend delete) in RSS is different from mentioned in related work, and here, these are based on some distributed methods}

When a participant willing to get a Manufacturer Role with EPC Object Class range 01.0000A11.[000200-000299].* in the ERBAC system, the decision is not made by itself, but depends on voting results from all its directly connected partners who received items from Company A with the EPCClass range from 01.0000A11.000200.* to 01.0000A11.000299.*. 

As in the example scenario depicted in Figure \ref{fig:rolegrant}, Company A wants the Role Manufacturer to be granted, it will ask RSS for granting and RSS will decide whether to grant the role to Company A depends on voting results from Companies, which are all the partners directly connected with Company A by transferred items within the EPC Object Class in range 01.0000A11.[000200-000299].*. 

\begin{figure}
		\centering
		\includegraphics[width=\fullwidth]{images/Panduan.pdf}
		\caption{Role Grant Activity Diagram}
		\label{fig:roleactivitydiagram}
	\end{figure}


In details, Figure \ref{fig:roleactivitydiagram} is the activity diagram for role grant. First of all, Company A invokes the web service \emph{grantRole()} on the RSS to send the Role Grant request. To send this request, Company should supply its \emph{Authentication Certificate} and the EPCClass or EPCClass range associated with the target role. In authentication, the X.509 defines the certificate that provides trustworthiness on public keys. Those public keys can be used to verify the digital signature and finally authenticate the access request. After receiving the request from Company A, RSS firstly authenticate A's \emph{Certificate}. If the authentication fails, RSS will return a null value indicates the fail of the request. Otherwise, RSS processes to look for all direct connected partners who have received item with EPC within the EPCClass or EPCClass range requested by Company A. RSS stores all the participants' address, it gets all directed partners from table \emph{itemTrack}. If this step succeeds too, the RSS will ask all partners to vote for Company A by invoking all the \emph{voting()} services on the partners' ERBAC servers. RSS provides its Authentication Certificate along with the voting requests. All partners authenticate RSS's certificate and then give their voting results back. The last step will be the RSS decide whether to grant the role based on the voting results it receives. Simple Majority Voting is employed here. RSS will only grant the role if more than the half of the voting results is positive. For those directly connected partners who do not vote for the role grant, when the applicant tries to access them with the granted role, they can ignore this general role and only use their perspective roles to compute the privileges for the requestor. Perspective roles have higher priority for the privilege computation when there are general role and perspective role assigned on the same company with same EPCClass or EPCClass range. Because information for perspective role grant is more detailed than general role grant, perspective roles are granted based on the direct connections and complete known of partners' information. (Due to the properties of the distributed environment, maybe not all the results can be received in a short time interval, so the system should employ some fault tolerance mechanisms to deal with it, this will be discussed in the further questions part \ref{summaryandfuturework.futurework}.)


\myFrameBigFigure	
					{sdroleGrant}
					{Role Grant Sequence Diagram }
					{Role Grant Sequence Diagram }
					
					
Figure \ref{image_sdroleGrant} is the sequence diagram of role grant, it explains in detail of requests' sequences and it specifies that the request from role applicant is a synchronous request and those requests from RSS to partners are asynchronous. RSS should not block when waiting for voting results from partners of the applicant.					

\subsection{Revoke roles}
\label{sec:rolerevoke}

Companies in the supply chain usually change its roles in a supply chain frequently. These changes could either cause by that a company choose new products to produce, or a company do not extend its role grant after it expired. Therefore, a \emph{Role Revoke} feature is necessary to revoke the expired roles or revoke roles by a request.

\myFrameBigFigure	
					{sdroleRevoke}
					{Role Revoke Sequence Diagram}
					{Role Revoke Sequence Diagram}

\ref{image_sdroleRevoke} is a sequence diagram depicting that a company wants to have its role revoked. In the figure, the role tends to be invoked is the role \emph{Manufacture}. In an ERBAC system, this role could be the role \emph{Manufacturer} or any other role that a company possesses. To revoke a role, the applicant invokes the \emph{revokeRole()} service on the RSS, it sends its Authentication Certificate, the target role's name and the EPCClass(es) associated with the role along with the service invocation. In the RSS side, after received a role revoke request, it firstly verifies Authentication Certificate of the applicant for the authentication purpose. If the authentication fails, the RSS returns a certificateVerifyFailed message to the applicant to tell its request has failed in the authentication phase. Otherwise, RSS process to check whether the target role with the EPCClass(es) has been granted to the applicant by checking its \emph{roleGrant} table. If the target role has not been granted to the applicant, RSS will send back a roleStatusVerifailed message to the manufacturer to indicate that the role it supplies is not valid in the RSS's point of view. If this step succeeds too, RSS starts to execute applicant's request, to revoke the role \emph{Manufacturer}. In essence, to revoke a role from a company means delete a specific record in the \emph{roleGrant} table in RSS. After deleted the specific record from its database, RSS sends a return value to requestor to indicate the whole process succeeds.

This is the case that a manufacturer chooses new products to produce and therefore wants to have its role with old products revoked. In the case that one company's role has expired, the role revocation request rises from RSS internally. RSS can revoke the role directly and send a message to the company to tell the revocation then. It is then the company's decision to either send a request to ask for a new role grant or just accept the result silently.

%\todo{add a paragraph discuss about how role revoke works in Single EPCIS server: Single EPCIS server can only revoke the Perspective Roles in its roletables, it has no knowledge about General Role assignment. To revoke a Perspective Role, single EPCIS server obey the rules mentioned in the related work \ref{}}

\subsubsection{Historical record access issue}

Company Toptech is a laptop manufacturer. It supplies fashion and high performance laptops to the market. In 2007, it produced a laptop named Slimpad2007 and made it popular in the market. Toptech used its ERBAC system to get a Manufacturer role from RSS with Slimpad2007's EPCClass. At the end of 2007, Toptech received a message from RSS said the role Manufacturer with Slimpad2007 had expired and therefore it had been revoked. As Toptech already had a new laptop type Slimpad2008, it decided not to extend the role grant for Slimpad2007, so it lost the \emph{Manufacturer} role for the Slimpad2007. Unfortunately, after the role revocation, some deficits on Slimpad2007's batteries have been revealed and this problem impacts Toptech's reputation. So Toptech decides to callback Slimpad2007.

To callback the Slimpad2007, Toptech needs the \emph{Manufacturer} role with Slimpad2007 to send a callback request to other participants in the supply chain. But after the role revocation, Toptech lost access to records about Slimpad2007 in other participants. Its access requests are rejected by the reason of role authentication. To solve this problem, Toptech has to send a request to RSS to ask for a Manufacturer role with Slim2007 again. As described in Figure \ref{image_sdroleGrant}, RSS asks for voting from Toptech's partners. Normally, companies keep their historical records, so Toptech's partners can make right decisions and vote for Toptech as they did once before. After Toptech get the \emph{Manufacturer} role with Slimpad2007, it can access to other companies to execute callback again.


\subsection{Add roles}
\label{sec:addrole}

When a participant finds that there is no role is suitable for its needs, it can send a request to RSS to ask for a role dictionary extend. To add a new role into RSS's Role Dictionary, an applicant should invoke the \emph{addRole()} service on the RSS. Role Dictionary is a table maintains existing roles' names. Role hierarchy is not necessary in the Role Dictionary because there are no privileges associated with roles in the RSS. 

\myFrameBigFigure	
					{sdroleExtend}
					{Role Extend Sequence Diagram}
					{Role Extend Sequence Diagram}

Figure \ref{image_sdroleExtend} is the sequence diagram of role extend. After received a role add request, RSS will authenticate the applicant first. If authentication fails, a message will be sent to the applicant to indicate that the authentication failed. If authentication succeeds, RSS processes to verify the existence of the target role. It searches its Role Dictionary to look for a role has the same name as the target role. If the search result is null, then the RSS processes to extend is role dictionary. Otherwise, RSS sends a roleExist message to the applicant. To keep the consistency of all Role Dictionaries, RSS has to broadcast a extend role message to all the participants in the supply chain if it decides to add the role to its Role Dictionary. These messages tell other participants that there is a new role has been added, someone could request a access with this role afterwards and participants should be prepare to assign proper privileges to the role. After received all the confirm messages from participants, RSS adds the target role into its own Role Dictionary, then returns an addSucceed message to the applicant. Then the added role is ready to be granted to participants.

%There always a need to add new roles to ERBAC system. To deal with this, there is a web service called Role Extend on the RSS, when a participant request to add any role in the role hierarchy (will be described in the Role Hierarchy part), it can simply invoke this web service. 
%For General role, the decision of adding or not adding the request role is made by Administrator(s) of RSS. The RSS maintains a role dictionary to 
%
%\subsection{Role Hierarchy}
%
%\todo {explain role hierarchies in participants' EPCIS servers}

\subsection{Delete roles}
\label{sec:deleterole}

When a company or a RSS administrator recognizes a role is not valuable any more, they can post a request to delete it. To delete a Perspective Role in a single participant's ERBAC server is relatively simple, because Perspective Roles are defined based on single participant's view on its directly connected partners, a participant can delete its Perspective Roles without any influence on other participants. The decision to delete a Perspective Role can be made by administrator of the ERBAC server independently. However, the decision making process is more complex to delete General Roles defined in the RSS. Deleting a General Role in a supply chain can influence either all the participants who have been assigned the role, or participants who have assigned some privileges to the target General Role. Therefore, to delete a General Role needs all participants' involvements.

\myFrameBigFigure	
					{sdroleDelete}
					{Role Delete Sequence Diagram}
					{Role Delete Sequence Diagram}

Figure \ref{image_sdroleDelete} is the sequence diagram of General Role delete feature. There is an applicant proposes a request to delete a General Role by invoking the \emph{deleteRole()} service on the RSS. The applicant supplies its Authentication Certificate with the target role's name. On the RSS side, after received the role delete request, it verifies applicant's certificate first. This authentication step is as the same as in the Figure \ref{image_sdroleGrant} and Figure \ref{image_sdroleRevoke}, so it is simplified here because of the size of the diagram. If authentication succeeds, RSS verifies the existence of the target role by search its name in its Role Dictionary. This step is already described in the \ref{image_sdroleExtend}, to maintain a proper size of the diagram, it is simplified in this diagram too. After the verification succeeds, RSS do a SQL search to get all the participants who have got the target role granted in its \emph{roleGrant} table. We call these participants the role owners. If the search result is null, that means no one possesses the role at that time. Then RSS can delete the target role directly and send a succeed message to the applicant. Otherwise, there are some role owners exist in the traceability network. RSS sends asynchronous messages to those role owners by invoking their \emph{roleDelete()} services. RSS waits until receives all the return messages from role owners. If not all of the return messages are positive, RSS will send applicant a reject message to indicate the failure of the role delete. If all the return messages from role owners are positive, RSS broadcasts role delete messages to all the participants to tell them to delete the role. After received all the confirm messages, RSS deletes the target role in its own Role Dictionary and sends a succeed message to the applicant.

The condition should be met for deleting a role when some role owners exist is strict. RSS should wait until it receives all the return messages to make a decision. This is totally necessary to protect the role owner's rights and maintain the consistency of the Role Dictionary in RSS and Role Hierarchies in participants' ERBAC servers.

There is also another case that RSS posts a request to delete a role when administrator on it regards a role in not valuable. The sequence is as the same as Figure \ref{image_sdroleDelete} only except that the applicant is RSS and authentication step is skipped.


%This happens on two occasions. 
%a)	Administrator on RSS posts a request to delete a role in the role dictionary. It will first do a sql search to get all the participants who have been granted the role. Then send requests to all of them and wait until received all the replies to make the decision. It is a little strict that RSS can not delete a role without all voting to agree even though this role is defined by itself, but this is totally necessary to protect the participants' rights and maintain the consistency of role dictionaries maintained on the RSS and participants. 
%For participants in the supply chain with the target role granted, they make their decision on the default settings about the role deletion. Commonly, there are three settings for decision making: 1. always agree. 2. always disagree. 3. decision involves human. The decision making setting is made to always agree when the system requirement.always disagree... decision involves human means this decision will be made by the administrator. For the period of waiting for decision from administrator, the reply will be suspend on the participant's EPCIS server, but there is a decision suspending reply will be sent back to RSS to avoid RSS thinking the EPCIS server on this participant is down and trig the fault tolerance mechanism (e.g. try to send the request second time). This will help for RSS make a right decision and save resources. If the RSS receive a decision suspending decision from one of the participant, it can send the thread for this participant to sleep and wake up it when receive a decision later. (Technically possible?)
%b)	When a role deletion comes from a participant with or without the target role granted, this request will be sent first to RSS. RSS will make its decision first, it will not forward this request to other participants who have been granted the target role if it does not support to delete the target role. RSS's decision making mechanism is much like its compeer in the participant's EPCIS server...add something if like 
%c)	Role update is a combination of role deletion and extension in essence. 


%\begin{figure}
%	\centering
%		\includegraphics[width=160mm]{images/ER.pdf}
%	\caption{A Pharmaceutical Supply Chain (~\fullcite{Theseos1}) }
%	\label{fig:ER}
%\end{figure}


%\section{A use case}
%\label{overallscenario}

%\todo{1. explain how will perspective roles and general roles be used in the access control for those company do not want to tell about its predecessor in the supply chain.\newline2.insert a diagram to explain all the participants' role and their relationships in the supply chain \newline3. insert a SEQUENCE DIAGRAM to show the certificate verification between CA and participants. }
